1. Field of the Invention
The present invention relates to a public key infrastructure system comprising a certification authority that issues a public key certificate revocation list, a server for certificate validation that verifies a validity of a public key certificate, and a client who uses the certificate validation server.
2. Description of the Related Art
[Patent Reference 1]: US 2002/0046340A1, [Non-Patent Reference 1]: ITU, ITU-T Recommendation X.509 “Information technology—Open systems interconnection—The Directory: Public-key and attribute certificate frameworks”, ITU, March 2000, p. 7-53, and [Non-Patent Reference 2]: “GPKI Government Public Key Infrastructure interoperability specification” p. 18-20, 27-29, “online”, Apr. 25, 2001, approved by Basic Problem Workgroup, “searched on Mar. 14, 2003”, Internet <URL:
http://www.soumu.go.jp/gyoukan/kanri/010514—2.pdf>teach CRLs, server models, and public keys.
Systems using the public key infrastructure (referred to simply as PKI) including a Government Public Key Infrastructure (GPKI), are coming into wide use to identify a person who produced an electronic document of interest and guarantee that the electronic document has not been changed or tampered with (see, for example, non-patent reference 1). In a PKI-based system, an electronic document is electronically signed by a person affixing his or her digital signature using a key called a private key, which is owned only by that person (referred to as a signatory). When an electronic document with a digital signature is received, the digital signature is verified to identify a producer of the electronic document and confirm that the electronic document is not tapered with.
In uses that require a high level of trust, to verify a digital signature requires not only verifying the digital signature of interest by using a key called a public key embodied in a public key certificate (simply referred to as a certificate) of the signatory but also checking whether or not the certificate of the signatory is a valid one for a person who verifies the digital signature (referred to as a verifier). To verify whether or not the certificate of the signatory is valid for the verifier, it is necessary to (1) discover a certification path and (2) verify the certification path.
The certification path is a chain of trust from the verifier to the signatory and is expressed in the form of a chain of certificates. Where the certification authorities issue certificates to each other, in particular, special certificates, called cross-certificates, are issued. When nine certification authorities from 11 to 19 have a cross-certification relationship with one another, as shown in FIG. 2, the certification path from a verifier having a certificate issued by the certification authority I2 to a signatory having a certificate issued by the certification authority I1 is a chain of certificates beginning with a cross-certificate 918 followed by a cross-certificate 968, a cross-certificate 946, a cross-certificate 924, and then finally a certificate of the verifier. A method of validating the certification path discovered in this manner is detailed in the above non-patent reference 1.
In one of the GPKI specifications, there are described an end entity model and a certificate validation server model as models for verifying the validities of certificates (see, for example, non-patent reference 2). The certificate validation server model uses a certificate validation server that provides a function to perform an online check on the validity of the certificate concerned on behalf of a client.
The certificate validation server model has the following advantages over the end entity model. First, since there is no need to mount a certification path discovery function on a client, the certificate validation server model can make the client signature verification program small. Further, because a client trusts the result of decision made by the certificate validation server, it is possible to flexibly cope with system configuration changes by simply changing a setting of the certificate validation server. According to the above non-patent reference 2, whether a particular certificate is valid or not is verified using a certificate revocation list (referred to as a CRL) issued by the certification authorities or an OCSP responder.
Since it is not efficient to retrieve the CRL from the certification authority every time a certificate validation is performed, the patent reference 1 discloses a method whereby the certificate validation server caches the certificates, the CRL and the certification path to increase the speed of the certificate validation process.
To verify a digital signature and build a certification path requires obtaining a certificate of the signatory.
The methods of obtaining a signatory certificate can be classed largely into two types.
One type of method involves a signatory sending an electronic document signed with a digital signature, with a certificate of the signatory to be obtained separately. One example of this method concerns a caser where a signatory sends an electronic document with a digital signature along with a URL that indicates the location where a certificate for verifying the digital signature is stored. With this method, the verifier needs to access the location where the certificate is stored (hereafter referred to as a certificate repository) to obtain the certificate.
Another type of method involves a signatory sending an electronic document with a digital signature along with a certificate that is used to verify the digital signature.
If a CRL is cached for an increased speed of the certificate validation process, when a certification authority issues a CRL in an urgent situation, the cached CRL is not the latest one any more. The patent reference 1 does not refer to this point.
One method for solving the above-mentioned problem to ensure that the certificate validation can be performed correctly even when the CRL is issued in an urgent situation, involves having the certificate validation server periodically access a location where the CRL is stored (hereinafter referred to as a CRL repository) to check if the CRL is updated. The above-described method is further classified into two types. One is to have the certificate validation server itself make a check via the network and another is to introduce CRL issuance check software into the CRL repository.
In enhancing the accuracy of the certificate validation by using the method of periodically checking whether or not the CRL is updated, it is necessary to shorten an interval between the checks as practically as possible. In the method where the certificate validation server itself makes a check through the network, however, shortening the check interval will give rise to a problem of increasing the load of the network.
In the method that introduces a CRL issuance check program into the CRL repository, on the other hand, there is a problem that if an administrator of the CRL repository and an administrator of the certificate validation server should differ, the installing of the CRL issuance check software is not permitted, leaving the check unperformable.
Further, in an environment where a plurality of certificate validation servers exist, all the certificate validation servers cannot perform the validation process with the same accuracy unless they all use the CRL issuance check software introduced into the CRL repository. So, if the number of operational certificate validation servers is to be increased or reduced, the setting of the CRL issuance check software needs to be changed. However, if the administrator of the CRL repository and the administrator of the certificate validation servers differ, it is difficult to flexibly change the number of certificate validation servers.
Another problem is that, if the certification path is cached but the certification authorities have revoked old cross-certificates and issued new cross-certificates, it is necessary to build a certification path including the new cross-certificates.
Further, in an environment in which there are a plurality of certificate validation servers, even if the plurality of certificate validation servers validate the same certificate, each of the certificate validation servers performs the certification path discovery and obtains the CRL. This raises a possibility of accesses concentrating on a particular CRL repository or on a particular certificate repository and also a possibility of an increased network load. The patent reference 1 does not refer to these problems.
Further, in the preceding method of obtaining the certificate separately, there is a problem that, to request the certificate validation server to verify the certificate, the client must first access the certificate repository to obtain the certificate.
Under these circumstances, a new technique for resolving these problems is being called for.